花名:神帅，毕业5年,混迹于大小厂打怪刷实战经验。资深Java开发工程师,是个宝爸,热爱生活做饭,读书,在企业服务领域和电商领域均有积累,
最近一直在研究DDD和低代码领域,对后端微服务业务平台架构的实践和发展比较感兴趣。
公众号:神帅的架构实战CSDN:https://blog.csdn.net/u010504064
大家好，我是业务组件部的神帅，很高兴大家来听我的分享。
下面我将通过6个小节给大家阐述一下本次的分享内容，首先将给大家介绍一下DDD的相关概念和理论，然后通过架构风格来衔接实战内容，好了，话不多说，我们开始。
为什么要了解DDD，DDD能给我们带来什么样的好处呢，本小节将着重介绍DDD相关的理论内容以及与设计模式的对比。这样可以更好理解DDD，是因为我在学习DDD之前先学了设计模式，是在大学的时候看了一本书叫《设计模式之禅》，今年看了eric的书《领域驱动设计》，发现里面很多模式都可以用设计模式的方式给固化下来，当作一个DDD模式去学习，这样理解起来也简单很多。
从软件开发角度来讲有11种开发模型，有4种开发模式，其中就有领域驱动设计，也是本次分享要重点介绍的内容。
很多人都在定义DDD是？或者说DDD不是什么？除了上面的定义问题也有人说DDD是一种建模方法？其实我个人倒觉得DDD是类似于武功心法一样的东西，可以提升开发功力，改变看待需求的角度,不局限于理论和架构。借用万物皆对象的说法，就是万象皆领域。
大家都知道DDD起源于国外，是一种比较新颖也比较难懂的理论方法。有些大佬对DDD奉为圭臬，有些则嗤之以鼻，
另一些就无所谓，不用DDD解决不了上面的问题吗？确实可以解决，但是依然很复杂，就是需要花费很大精力去解决这些问题。
而DDD要解决的问题就是降低软件复杂度，分离技术和业务需求，进行领域建模沉淀可复用可扩展的业务模型和工程代码。
先回顾一下设计模式有哪些内容，概括起来就是23+6，23种设计模式加6大原则
那现在先简单看一下DDD的模式有哪些，很多了解过DDD的人都知道DDD包括战术模式和战略模式，这里我从ERIC的书中总共抽取了40多个模式，也包括一些其他的书中特别提到的模式，比如事件溯源模式。
现在看一下DDD与设计模式的区别，在DDD的眼里设计模式是偏技术实现的，不包含业务领域的，所以DDD首要考虑的是如何建模如何表达实体和值对象等等。当然次要的就是将设计模式中的一些模式拿来当战术模式用，比如策略模式和工厂模式，但是不局限于怎么实现策略或者工厂。
另外一方面DDD更关注一些战略层面的事情比如说上下文的协同，迭代开发对应的软件价值交付。而设计模式更关注于逻辑代码是否可以降低实现的复杂度，提高可扩展性和可读性，符合一些开发规范。
事件风暴建模法这种方法比较适用于团队，比如说一帮人在会议室里讨论业务需求，用白板和便签构建领域事件，
描述领域对象。最后构建领域模型。
限界笔纸法来源于TW的资深大佬，其本质上是对四色建模法的一种升级，将建模过程用纸和笔记录下来，形成表格。然后从这些表格实例中抽取实体和值对象，确定这些实体和值对象的聚合关系。
上图是CQRS架构的一个典型架构图，其核心就是将读和写进行分离，同时对写按命令场景去区分，
对读进行统一抽象。
但是很多情况下这个架构并不是我们首选的一种方式，后面会讲到。
在我看来洋葱架构很好的表达了DDD在不同架构风格的位置，说白了DDD所要表达的内容就是核，将需求建模成一个核，底层的技术组件和上层的用户接口以及测试用例都是围绕核来建设的。上图是洋葱架构的一种形式，另外一种形式就是基础设施作为核心，将Object Model和Service融入到核心的外层。
在洋葱架构中其要表达的核心思想就是，外层调用只能调用内层，不允许进行跨层调用。
COLA架构是我很早就接触过的一种架构思想，当时还在2.0阶段，我刚一看到也是一脸不屑，以为跟网易的COLA有啥关系，后来经过详细了解和揣摩之后发现这个架构的兼容性和扩展性以及适配性都比较好。当然这个图也很好的融合了整洁架构，适配器架构和洋葱架构的特点。
很多时候一个大型项目其实不止一种架构风格，比如DDD的分层架构和上述的COLA架构，这里其实可以将DDD的分层架构与CQRS架构进行融合，首先看写调用，调用流程正常走分层架构模式，中间加了一个cmd命令模型,exe执行器模块进行业务逻辑串联，读调用就可以单独走服务接口，正好与读写分离是相通的。
当我们要落地DDD的时候就会遇到一个问题DDD的很多东西都放在哪里，怎么跟框架进行结合，网上也很少有案例。技术组件知道都放在基础设施层里，但是其他代码元素比如dto,实体，值对象，仓库这些应该怎么放.怎么去匹配dubbo等技术框架，怎么跟其他层的代码元素进行交互完成业务逻辑。
这里其实借鉴了COLA架构和DDD分层架构来画的一张图。比较明显的是领域层是可以单独拿出来的.这也与之前的讲述是一致的.DDD建模就是要表达业务需求的核心内容，当作核来看待。因此这个领域层的Jar会被应用层和基础设施层分别引用。
前面几小节已经讲述了DDD的理论模式和业务架构风格，这里我们就进入实战环节，看看如何使用DDD来构建一个博客帖子平台。
这里使用四色建模法来构建模型图。限于篇幅我大概讲一下建模过程，先确定业务关键时刻，如上图的博客/帖子/微博等。然后针对这个对象产生了一些其他相关的业务活动，我们对这些相关的业务互动继续建模，为其添加角色和描述则得到了上图的建模内容。
我们用四色建模法得到的模型图来继续构建UML类图，在这个类图中我们对相关的业务对象抽象了一些业务行为，如上图。
这里借助cola分包的策略来构建博客帖子平台的整体工程包内容，另外这也相当于用了DDD的战术模式--模块模式
这里我们看一下发布博客帖子的时候涉及到哪些领域，以及这些领域的上下文关系，我们从这些领域的交互中能提炼哪些事件消息。
这里我们看一下发布博客的整体流程，假设这是有多个业务服务构成的业务流程，先由博客领域发起业务活动，
然后由下游的审批服务和运营服务辅助博客领域完成发布博客的业务操作。
在博客核心服务的内部，我们看一下运用CQRS模式来编写发布博客的整体业务调用流程。这里将博客核心服务分为四层进行建设，有区别的地方就在于读的地方是不一定要先走领域层再到基础设施层的，在松散分层架构下这种情况也是允许的。经过上面的实战之后，这里我也简单列一些关于DDD的最佳实践。如果要用DDD解决问题的话，我们需要做哪些内容呢，首先是团队整体需要认可DDD的思想有意愿用DDD。一个人玩DDD容易达到瓶颈。后续就可以按照DDD的一些模式来构建文档和代码，如此循环。
下面我们看一些DDD落地的策略，防止落地过程中出现各种各样的问题。对于第二，三，四点我要表达的意思就是说团队中不要因为这些架构，框架和规范的因素影响我们使用DDD。对DDD的理解不同的人有不同的看法有时候会有偏见，在进行DDD建模落地到代码的时候，就很容易导致问题。
本文由神帅投稿。
往期推荐：
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。